Codecov Report

Merging #999 (13e5c1e) into master (504e084) will decrease coverage by 0.01%.
The diff coverage is n/a.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@            Coverage Diff             @@
##           master     #999      +/-   ##
==========================================
- Coverage   59.21%   59.20%   -0.01%     
==========================================
  Files         105      105              
  Lines       14054    14054              
==========================================
- Hits         8322     8321       -1     
- Misses       5732     5733       +1     

see 1 file with indirect coverage changes

So it pretty much works, according to CI testing. A quick double-check indicates that 5.15 is getting installed there:

pyqt                      5.15.7           py38ha0d8c90_3    conda-forge

On the PCDS side, we have a desire to use 5.15 for our general runtime/data acquisition environment. As we all know at this point, if you want Qt Designer to work with PyDM plugins, you have to pin to another specific version due to conda-forge's removal of a necessary shared library in recent releases. For that, we intend to keep a designer-only environment available that allows screen development to continue.

So, if PyDM's <5.15 pinning is relaxed to =5, we'll be free to adjust our pyqt pinning at the environment level.

I'll mark this as ready for review to get input. Would this PR or the above environment creation methodology be problematic for the accelerator (or other PyDM users)?

My thoughts are:

• Is there any reason to keep the pin in order to make sure people get the pyqt builds with proper designer support?
• After removing this pin, do we need to test against multiple versions of pyqt to make sure we don't stumble into regressions for people who are running the older versions with proper designer support?

Otherwise, I agree with the change. Extraneous upper pins cause more problems than they solve.

Would this PR or the above environment creation methodology be problematic for the accelerator (or other PyDM users)?

Is there any reason to keep the pin in order to make sure people get the pyqt builds with proper designer support?

There would be no issue on the accelerator side, we can pin at the environment level as well. And the workaround of just copying over the libpyqt5.so file as mentioned near the end of #866 still works for now at least, though not exactly robust.

Maybe a note added to our installation documentation with the command for creating a designer compatible environment would be helpful, especially for other pydm users as well. (I could add as a followup if you'd like)

After removing this pin, do we need to test against multiple versions of pyqt to make sure we don't stumble into regressions for people who are running the older versions with proper designer support?

This sounds like a good idea. I want to take a look at our pipelines already (maybe switching to mamba at least to fix the long build issues, maybe move to github actions entirely). Adding old and new pyqt could be done there as well.

Overall though I agree with the change as well, gives users the choice whether to pin or not as needed.